A client is any entity which receives data supplied by a server. Clients of a data server may include, for example, a process on the same node as the data server, a process on a different node than the data server, or a thread within a process. In a multi-process client/server computer system, a data server usually supplies data to multiple clients. The maximum rate at which a data server can supply data is known as the bandwidth of the server. The bandwidth of a server must be shared among the clients of the data server.
Clients of data servers can be classified as either real-time clients or non-real-time clients. In order to function properly, real-time clients require data at set times and at a relatively constant rate. Data that arrives late typically is useless to real time clients and can cause them to function improperly. For example, data for movie frames from a video server that arrives too late to be shown cannot be used and causes a visible momentary interruption of the movie. Timing is not so critical to non-real time clients. In order to function properly, non-real time clients do not require data at set times and may use data at varying rates.
Typically, the bandwidth of a data server is allocated in a manner that ensures that the constraints of real-time clients are met. Each real-time client is allocated a portion of the bandwidth to ensure that data is received at the constant rate required for the real-time client to function properly. The portion of bandwidth remaining after allocation to the real-time clients is shared among the non-real-time clients. The allocation to a non-real-time client is not constant because, unlike a real-time client, a non-real-time client can function properly while receiving data at varying rates.
To adapt to changes in the use of data from data servers by the clients of the data server, the allocations of bandwidth to the non-real-time clients is adjusted dynamically. One approach to changing allocations of bandwidth to clients is the client polling approach. In the client polling approach, at set time intervals a non-real-time client transmits messages to the data server seeking an adjustment to the amount of bandwidth allocated to the non-real-time client.
Transmitting messages between a client and server can require a lot of overhead, especially when a client resides on one node and the server resides on another node. One measure used to reduce the overhead incurred in transmitting messages is to increase the time between the time intervals at which a non-real-time client polls the server. Another measure is to limit the particular non-real-time clients that may poll a server to a subset of non-real-time-clients.
The client polling approach presents a few disadvantages. One disadvantage is that adjustments to bandwidth allocations are triggered by the passage of time, rather than by the events that create the need to re-adjust the bandwidth allocation. As a consequence, clients often poll servers, incurring the overhead of transmitting a message, when no adjustment of the allocation of the bandwidth is needed. Furthermore, when the need to adjust the allocation of bandwidth to a non-real-time client arises, the allocation can not be adjusted until the non-real-time client polls the server.
The delay caused by waiting for a non-real-time client to poll a server before adjusting the bandwidth allocation to that non-real-time client is especially disadvantageous when a new client requests access to a data server whose bandwidth has been fully allocated. To make bandwidth available to the new client, the bandwidth allocations to current non-real-time clients must be reduced. Consequently, the allocation to the new client is postponed until the necessary non-real-time clients poll the data server and have their allocated bandwidth reduced. This postponement can cause an unacceptably long delay in responding to the requests of new clients.
To avoid incurring this long delay, allocation of the full bandwidth of data server is avoided. The unallocated portion of the bandwidth serves as a reserve that is immediately available to new clients. When a portion of the bandwidth is allocated to a new client, the reserve is diminished. To replenish the reserve, the current allocation to each non-real-time client may be reduced if and when that non-real-time client next polls the server. If a client requests access when there is no reserve available, the request is denied. The risk of denial can be decreased by increasing the reserve.
Unfortunately, use of the reserve entails a tradeoff between reducing the risk of denying a new request by a new client for access to a data server and the throughput of the server, especially the throughput to non-real-time clients. To reduce the risk of denying a request for access by new clients, the portion of the bandwidth held in reserve may be increased. However, this increase in the reserve reduces bandwidth allocated to the non-real-time clients, thus decreasing throughput to them.
Based on the foregoing, it is clearly desirable to allocate a larger portion of the bandwidth to non-real-time clients without increasing the risk of denial of a request by a new client, and without increasing latency to an unacceptable level in responding to new requests. It is further desirable to avoid the overhead caused by a non-real-client periodically polling a data server for adjustments to the allocation of bandwidth to the non-real-time client.